Chaos CD Blue

home *** CD-ROM | disk | FTP | other *** search

/ Chaos CD Blue / Chaos_CD_Blue__[1999].iso / contrib / security / ssh-faq < prev

Wrap

Internet Message Format | 1999-11-21 | 37KB

Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!thetimes.pixel.kodak.com!news.kodak.com!news-pen-16.sprintlink.net!170.48.15.8!newton.hlthsrc.com!news-pen-15.sprintlink.net!news.nysernet.net!207.154.12.10!news.dgsys.com!news-pen-4.sprintlink.net!news-east.sprintlink.net!news-dc-26.sprintlink.net!news-peer.sprintlink.net!news.sprintlink.net!Sprint!newsfeed.nacamar.de!fu-berlin.de!uniol!news.uni-stuttgart.de!rz.uni-karlsruhe.de!not-for-mail From: Thomas.Koenig@ciw.uni-karlsruhe.de Newsgroups: comp.security.ssh,comp.security.unix,comp.security.misc,sci.crypt,comp.answers,sci.answers,news.answers Subject: SSH (Secure Shell) FAQ - Frequently Asked Questions Supersedes: <ssh-faq_862849823@fg70.rz.uni-karlsruhe.de> Followup-To: comp.security.ssh Date: 25 Jun 1997 15:29:31 +0200 Organization: =?ISO-8859-1?Q?Universit=E4t_Karlsruhe_(TH),_Germany_?= Lines: 980 Sender: ig25@fg70.rz.uni-karlsruhe.de Approved: news-answers-request@MIT.Edu Expires: 6 Aug 1997 13:25:36 GMT Message-ID: <ssh-faq_867245136@fg70.rz.uni-karlsruhe.de> NNTP-Posting-Host: fg70.rz.uni-karlsruhe.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit NNTP-Posting-User: ig25 Xref: senator-bedfellow.mit.edu comp.security.ssh:1993 comp.security.unix:39499 comp.security.misc:41257 sci.crypt:66953 comp.answers:26736 sci.answers:6638 news.answers:105793 Archive-name: computer-security/ssh-faq Url: http://www.uni-karlsruhe.de/~ig25/ssh-faq/ Posting-frequency: every 28 days -----BEGIN PGP SIGNED MESSAGE----- Ssh (Secure Shell) FAQ - Frequently asked questions by Thomas Koenig Thomas.Koenig@ciw.uni-karlsruhe.de $Date: 1997/06/06 17:19:04 $ This document is a list of Frequently Asked Questions (plus hopefully correct answers) about the Secure Shell, ssh. ______________________________________________________________________ Table of Contents: 1. Meta-questions 1.1. Where do I get this document? 1.2. Where do I send questions, corrections etc. about this document? 2. Ssh basics 2.1. What is ssh? 2.2. Why should I use it? 2.3. What kinds of attacks does ssh protect against? 2.4. What kind of attacks does ssh not protect against? 2.5. How does it work? 3. Obtaining and installing ssh 3.1. What is the latest version of ssh? 3.2. May I legally run ssh? 3.3. What about commercial use of ssh? 3.4. Where can I obtain ssh? 3.5. How do I install it? 3.6. Does it make sense to install ssh as non-root under UNIX? 3.7. Where do I get help? 3.8. Are there any versions for other operating systems than UNIX? 3.9. What about administration of ssh? 4. Ssh Applications 4.1. Can I run backups over ssh? 4.2. Should I turn encryption off, for performance reasons? 4.3. Can I use ssh to communicate across a firewall? 4.4. Can I use rdist with ssh? 4.5. Can I use ssh to securely connect two subnets across the Internet? 4.6. Can I use ssh to securely forward UDP-based services, such as NFS or NIS? 4.7. Can I forward SGI GL connections over ssh? 4.8. Can I use ssh to protect services like ftp or POP? 4.9. Can I use ssh across a Socks firewall? 4.10. Is there ssh support for AFS/Kerberos? 5. Problems 5.1. ssh otherhost xclient & does not work! 5.2. Ssh fails with "Resource temporarily unavailable" for Solaris 5.3. Sshd hangs under Solaris 2.5! 5.4. X11 forwarding does not work for an SCO binary with the iBCS2 emulator under Linux. 5.5. Ssh is doing wrong things for multi-homed hosts! 5.6. Userid swapping is broken under AIX! 5.7. ssh-keygen dumps core on Alpha OSF! 5.8. ssh-keygen dumps core on Solaris or SunOS 5.9. On Linux, compilation aborts with some error message about libc.so.4 5.10. X authorization sometimes fails. 5.11. Ssh asks me for passwords despite .rhosts! 5.12. Why does ssh loop with "Secure connection refused'? 5.13. ssh-agent does not work with rxvt! 5.14. X authorization always fails. 5.15. ssh hangs when forwarding multiple TCP connections. 5.16. What does Warning: remote host denied X11 forwarding mean? 5.17. I still see cleartext packages on the net when I run ssh! 5.18. I have problems with RSAREF, something to do with too many bits! 5.19. Compiling fails with some error messages from the assembler. 5.20. Compiling with Solaris 2.5 fails! 5.21. Ssh suddenly drops connections! 5.22. Connections are forwarded as root by ssh! 6. Miscellaneous 6.1. What known security bugs exist in which versions of ssh? 6.2. How widespread is use of ssh? 6.3. I don't like the commercial aspects of ssh. 6.4. Credits ______________________________________________________________________ 1. Meta-questions 1.1. Where do I get this document? The latest version of this document is available from http://www.uni- karlsruhe.de/~ig25/ssh-faq/. It will also be posted, on a regular basis, to the Usenet newsgroups comp.security.misc, comp.security.unix, sci.crypt, comp.answers, sci.answers and news.answers. This version is PGP-signed, and will be available from ftp://rtfm.mit.edu/pub/usenet/news.answers/computer-security/ssh-faq and from http://www.uni-karlsruhe.de/~ig25/ssh-faq/ssh-faq.faq. The original SGML file is at http://www.uni-karlsruhe.de/~ig25/ssh- faq/ssh-faq.sgml. You can download a gzipped PostScript version from http://www.uni-karlsruhe.de/~ig25/ssh-faq/ssh-faq.ps.gz. If your link to Germany is slow, you might get better connectivity at http://aleph1.mit.edu/ssh-faq/. Also of interest is the ssh home page, at http://www.cs.hut.fi/ssh/. 1.2. Where do I send questions, corrections etc. about this document? Please send them to the maintainer, Thomas.Koenig@ciw.uni-karlsruhe.de 2. Ssh basics 2.1. What is ssh? To quote the README file: Ssh (Secure Shell) is a program to log into another computer over a network, to execute commands in a remote machine, and to move files from one machine to another. It provides strong authentication and secure communications over unsecure channels. It is intended as a replacement for rlogin, rsh, and rcp. Additionally, ssh provides secure X connections and secure forwarding of arbitrary TCP connections. 2.2. Why should I use it? The traditional BSD 'r' - commmands (rsh, rlogin, rcp) are vulnerable to different kinds of attacks. Somebody who has root access to machines on the network, or physical access to the wire, can gain unauthorized access to systems in a variety of ways. It is also possible for such a person to log all the traffic to and from your system, including passwords (which ssh never sends in the clear). The X Window System also has a number of severe vulnerabilities. With ssh, you can create secure remote X sessions which are transparent to the user. As a side effect, using remote X clients with ssh is more convenient for users. Users can continue to use old .rhosts and /etc/hosts.equiv files; changing over to ssh is mostly transparent for them. If a remote site does not support ssh, a fallback mechanism to rsh is included. 2.3. What kinds of attacks does ssh protect against? Ssh protects against: o IP spoofing, where a remote host sends out packets which pretend to come from another, trusted host. Ssh even protects against a spoofer on the local network, who can pretend he is your router to the outside. o IP source routing, where a host can pretend that an IP packet comes from another, trusted host. o DNS spoofing, where an attacker forges name server records o Interception of cleartext passwords and other data by intermediate hosts. o Manipulation of data by people in control of intermediate hosts o Attacks based on listening to X authentication data and spoofed connection to the X11 server. In other words, ssh never trusts the net; somebody hostile who has taken over the network can only force ssh to disconnect, but cannot decrypted or play back the traffic, or hijack the connection. The above only holds if you actually use encryption. Ssh does have an option to use encryption of type "none" this is only for debugging purposes, and should not be used. 2.4. What kind of attacks does ssh not protect against? Ssh will not help you with anything that compromises your host's security in some other way. Once an attacker has gained root access to a machine, he can then subvert ssh, too. If somebody malevolent has access to your home directory, then security is nonexistent. This is very much the case if your home directory is exported via NFS. 2.5. How does it work? For more extensive information, please refer to the README and RFC files in the ssh directory. The proposed RFC is also available as an Internet Draft from ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls- ssh-00.txt. All communications are encrypted using IDEA or one of several other ciphers (three-key triple-DES, DES, RC4-128, TSS, Blowfish). Encryption keys are exchanged using RSA, and data used in the key exchange is destroyed every hour (keys are not saved anywhere). Every host has an RSA key which is used to authenticate the host when RSA host authentication is used. Encryption is used to protect against IP-spoofing; public key authentication is used to protect against DNS and routing spoofing. RSA keys are also used to authenticate hosts. 3. Obtaining and installing ssh 3.1. What is the latest version of ssh? The latest officially released version is is 1.2.20. Ssh currently runs on UNIX or related systems, plus under OS/2. Ports have been successful to all "mainstream" UNIX systems. There are two versions for MS-Windows. There is a free beta version by Cedomir Igaly, which can be obtained from http://public.srce.hr/~cigaly/ssh or, preferably, from a mirror at ftp://hotline.pvt.net/pub/win_utils/winsock/ssh/. There's also a commercial version by Tatu Yloenen, the original author of ssh. There's also a beta version for the Mac, available from Datafellows. 3.2. May I legally run ssh? The UNIX version of ssh 1.2.20 may be used and distributed freely, but must not be sold commercially as a separate product, as part of a bigger product or project, or otherwise used for financial gain without a separate license. Earlier versions of ssh had a less restrictive license; see the file COPYING in the accompanying source distributions. Tatu Yloenen's MS-Windows version of ssh is a commercial product, which requires licensing. In some countries, particularly France, Russia, Iraq, and Pakistan, it may be illegal to use any encryption at all without a special permit. If you are in the United States, you should be aware that, while ssh was written outside the United States using information publicly available everywhere, the US Government may consider it a criminal offence to export this software from the US once it has been imported, including putting it on a ftp site. Contact the Office of Defence Trade Controls if you need more information. The algorithms RSA and IDEA, which are used by ssh, are claimed as patented in different countries, including the US. Linking against the RSAREF library, which is possible, may or may not make it legal to use ssh for non-commercial purposes in the US. You may need to obtain licenses for commercial use of IDEA; ssh can be configured to work without it. Ssh works perfectly fine without IDEA, however. For more detail, refer to the file COPYING in the ssh source distribution. For information on software patents in general, see the Leauge for Programming Freedom's homepage at http://lpf.org/. 3.3. What about commercial use of ssh? Ssh has been freely available in the Unix environment, and almost certainly will remain to be so in future. Tatu Yloenen, the original author of ssh, has started a company, SSH Communications Security Oy, that will provide commercial support and licenses for ssh. This company is working together with Data Fellows, who are the sole contact for licensing ssh. More information can be found at http://www.europe.datafellows.com/ and http://www.ssh.fi/. 3.4. Where can I obtain ssh? The central site for distributing ssh is ftp://ftp.cs.hut.fi/pub/ssh/. Official releases are PGP-signed, with the key ID DCB9AE01 1995/04/24 Ssh distribution key <ylo@cs.hut.fi> Key fingerprint = C8 90 C8 5A 08 F0 F5 FD 61 AF E6 FF CF D4 29 D9 The latest development version is available from ftp://ftp.cs.hut.fi/pub/ssh/snapshots/. Ssh is also available via anonymous ftp from the following sites: Australia: ftp://coombs.anu.edu.au/pub/security/tools Chile: ftp://ftp.inf.utfsm.cl/pub/security/ssh Finland: ftp://ftp.funet.fi/pub/unix/security/login/ssh Germany: ftp://ftp.cert.dfn.de/pub/tools/net/ssh Hungary: ftp://ftp.kfki.hu/pub/packages/security/ssh Ireland: ftp://odyssey.ucc.ie/pub/ssh Poland: ftp://ftp.agh.edu.pl/pub/security/ssh Portugal: ftp://ftp.ci.uminho.pt/pub/security/ssh Russia: ftp://ftp.kiae.su/unix/crypto Slovenia: ftp://ftp.arnes.si/security/ssh United Kingdom: ftp://ftp.exweb.com/pub/security/ssh United States: ftp://ftp.net.ohio-state.edu/pub/security/ssh United States: ftp://ftp.gw.com/pub/unix/ssh Some mirrors may not have the most recent snapshots available. 3.5. How do I install it? Get the file from a site near you, then unpack it with gzip -c -d ssh-1.2.20.tar.gz | tar xvf - then change into the directory ssh-1.2.20, read the file INSTALL, and follow the directions in it. 3.6. Does it make sense to install ssh as non-root under UNIX? You can install and run a ssh binary, which you can use to log into another system on which sshd is running. If you want to log in to the remote system without typing in your password, you'll have to generate a private key in your home directory using ssh-keygen, then put your public key into $HOME/.ssh/authorized_keys. You can also start up sshd yourself as non-root, supplying the -p option so it binds to a non-privileged port (>1024), and then connect from another system with ssh -p. This will only allow connections to your own account, and sshd will, as a rule, not be restarted when your machine reboots. You will have to decide wether this is useful for you or not. 3.7. Where do I get help? First of all, read the documentation, this document :-) and the ssh home page, at http://www.cs.hut.fi/ssh/. For users, there is an introduction at http://www.tac.nyc.ny.us/~kim/ssh/. If these resources don't help, you can post to the Usenet newsgroup comp.security.ssh or send mail to the gatewayed mailing list for ssh users at ssh@clinet.fi. To subscribe, send mail to majordomo@clinet.fi with subscribe ssh in the body of the message. Before subscribing, you might like to take a look at the archives of the mailing list, at http://www.cs.hut.fi/ssh/ssh-archive. 3.8. Are there any versions for other operating systems than UNIX? Heikki Suonsivu (hsu@clinet.fi) and Michael Henits (moi@dio.com) each offered a US$ 100 reward for the first stable, freely redistributable version for either MS-Windows or MacOS. There was a preliminary version for MS-Windows by Cedomir Igaly. Unfortunately, it does not appear to be available any more. You can try out archie; look for the filename ssh-1-2-.zip. The commercial version by Tatu Yloenen, the original author of ssh, is available from http://www.europe.datafellows.com/f-secure/fssh- reg.htm. Bernt.Budde@udac.uu.se is working on a Mac port. A port to VMS, by Mark Martinec (Mark.Martinec@nsc.ijs.si), is being worked on. A port to OS/2 can be obtained from ftp://ftp.cs.hut.fi/pub/ssh/os2/. There is a special mailing list for the OS/2 version of ssh. To subscribe, send mail to majordomo@clinet.fi with subscribe ssh-os2 in the body of the message. 3.9. What about administration of ssh? The central problem of administering ssh is the management of host keys. To allow a client to connect to a remote host with RSA host authentication, the server needs to know the client's public key. You can collect these automatically each night using either make-ssh- known-hosts.pl (distributed with the ssh source distribution) or with the much faster ssh-keyscan, from ftp://cag.lcs.mit.edu/pub/dm/ (also available from ftp://ftp.cs.hut.fi/ssh/contrib/). Thomas Koenig has written a script to process output from one of these utilities, check for new keys, warn about hosts which have changed their keys (which could be an indication of a man in the middle attack) and generate a complete new file. This script is available from http://www.uni-karlsruhe.de/~ig25/ssh-faq/comp-host-list. With these utilities, you can write scripts to verify public keys on a regular basis. When new machines are running ssh or people have changed public keys, you may want to contact the people in question directly, to make sure there were no man in the middle attacks (to which these utilities are vulnerable). A fingerprint scheme (equivalent to PGP fingerprints) has been proposed to make this easier; it will probably be implemented in the next release. 4. Ssh Applications 4.1. Can I run backups over ssh? Yes. Since ssh is a drop-in replacement for rsh, backup scripts should continue to work. If you use rdist, see below. 4.2. Should I turn encryption off, for performance reasons? No; you should keep it turned on, for security reasons. Today's CPUs are fast enough that performance losses (if any) only are noticable for local Ethernet speeds, or faster. You might want to specify blowfish encryption instead of the default, IDEA, with -c blowfish, for faster operation. Following are some measurements where the different encryption methods were applied between a P5/90 and a 486/100, both running Linux, for copying files with scp across a lightly loaded Ethernet. The model chosen was t=a+x/b; a is the startup time in seconds, and b the sustainable transfer rate in kB/s. Also given are the 68.3% confidence intervals for the data, as determined by the Levenberg- Marquardt algorithm as implemented a pre-3.6 version of gnuplot. Encryption a[s] da[s] b[kB/s] db[kB/s] none 2.37 0.37 386.1 5.8 rc4 1.96 0.27 318.2 2.9 tss 2.33 0.37 298.5 3.5 des 2.07 0.19 218.8 1.0 idea 2.25 0.45 169.6 1.3 3des 1.92 0.11 118.2 0.2 Across a heavily loaded Ethernet, rc4 encryption together with compression may actually be faster than using rcp. If you don't encrypt your sessions, you are vulnerable to all the attacks which are open on the "r" suite of utilities, and you might as well not use ssh. 4.3. Can I use ssh to communicate across a firewall? Yes; you can use TCP forwarding for that, by using its secure TCP forwarding features. 4.4. Can I use rdist with ssh? Stock rdist 6.1.0 does not work together with ssh, due to bugs in it. The 6.1.1 versions of rdist and later versions are believed to work. If you use rdist, don't forget to compile the path to ssh into it. Alternatively, you may specify the -P option so rdist uses ssh, and not rsh. If you use password authentication with rdist 6.1.2 or 6.1.3, you will need to apply the following patch to rdist to make it work: --- src/rshrcmd.c.orig Tue Jun 11 16:51:21 1996 +++ src/rshrcmd.c Tue Jun 11 16:52:05 1996 @@ -63,7 +63,7 @@ /* child. we use sp[1] to be stdin/stdout, and close sp[0]. */ (void) close(sp[0]); - if (dup2(sp[1], 0) < 0 || dup2(0,1) < 0 || dup2(0, 2) < 0) { + if (dup2(sp[1], 0) < 0 || dup2(0,1) < 0) { error("dup2 failed: %s.", SYSERR); _exit(255); } <p> This also applies if you get a "Warning: Denied agent forwarding because the other end has too old version." error (which occurs if your client is 1.2.17 or later, and it connects to an older server). Another alternative would be to use rsync, a rdist replacement, which was designed to work with ssh, and makes better use of bandwidth. More information can be found at ftp://samba.anu.edu.au/pub/rsync or ftp://sunsite.auc.dk/pub/unix/rsync. 4.5. Can I use ssh to securely connect two subnets across the Inter- net? You can run PPP over a regular ssh connection. See http://www.inka.de/~bigred/sw/ssh-ppp-new.txt for a working solution. It's a good idea to enable compression for this. However, this may cause problems for forwarding TCP connections, because both the TCP connection over which ssh runs and a TCP connection forwarded over the PPP/ssh tunnel may retransmit at the same time. In this case, it is better to use encrypted IP tunneling via UDP. A possible implementation of this is http://www.inka.de/~bigred/devel/cipe.html. 4.6. Can I use ssh to securely forward UDP-based services, such as NFS or NIS? There is a general working solution for RPC-based services, such as NIS. You can download it from ftp://ftp.tu- chemnitz.de/pub/Local/informatik/sec_rpc/. NIS, in particular, is working. In principle, this could also be adapted for NFS; this has not been done yet. Services which are based purely on UDP, such as DNS, have not been secured with ssh yet, although it is possible in principle. 4.7. Can I forward SGI GL connections over ssh? It is not likely that this will be implemented. GL uses a totally different protocol from X, and at least gld would have to be replaced. OpenGL, when run as an X server extension, should pose no problem. You may need to set the environment variable GLFORCEDIRECT=no. 4.8. Can I use ssh to protect services like ftp or POP? If you want to avoid sending ftp passwords in cleartext over the net, you can use ssh to encrypt your command channel. This will still leave your data channel open to all attacks on TCP, and will not work through a firewall. Suppose you are on a host called myhost and want to initiate a ftp connection to ftphost. On myhost, you do myhost$ ssh -L 1234:ftphost.do.main:21 ftphost This logs you on to ftphost and also forwards connections to 1234 on myhost to ftphost. Then, in another window, you do myhost$ ftp mymachine 1234 220 ftphost FTP server (Foonix 08/15) ready. Name: (myhost:yourname): 331 Password required for yourname Password: 230 User yourname logged in. This works if the remote ftp daemon accepts PORT commands which specify a different host from the one the command channel appears to come from, and if the ftp client always uses PORT. This is true for vanilla UNIX ftp client and ftpd servers; it may not work for more advanced ftpds, such as wu-ftpd. For servers which do not accept this, you can see wether you ftp client supports passive mode, and wether the ftp server accepts PASV. For POP, Stephane Bortzmeyer (bortzmeyer@pasteur.fr) has written a script which protects the mail transfer and passwords ussing ssh. It requires no modification to existing POP servers or clients, and is available from ftp://ftp.pasteur.fr/pub/Network/gwpop/. Other services could be secured by similar means. Note, however, that unencrypted ftp data connections are still vulnerable to session hijacking and snooping. 4.9. Can I use ssh across a Socks firewall? Socks 5 support should work in 1.2.16 or later. 4.10. Is there ssh support for AFS/Kerberos? At the moment, not in the main sources. There's an AFS patch available from http://www-personal.umich.edu/~dugsong/ssh-afs- kerberos.html which should make it into the contrib directory shortly. 5. Problems If you don't find your problem listed below, please submit a bug report to ssh-bugs@clinet.fi giving full details of o Version number of ssh and (if different) sshd o What you expected ssh to do o What ssh did instead (including all error messages) o The system you use (for example, the output of uname -a), and the output of config.guess. o For a compilation problem, the contents of the file config.log (generated by configure) o The compiler you used, plus any compilation flags o The output of ssh -v o The output of the sshd daemon when run in debug mode, as sshd -d Please try the latest snapshot from ftp://ftp.cs.hut.fi/pub/ssh/snapshots/ before reporting any bug. 5.1. ssh otherhost xclient & does not work! No, it doesn't. Use "ssh -f otherhost xclient" instead, or "ssh -n otherhost xclient &" if you want a script to be compatible with rsh. 5.2. Ssh fails with "Resource temporarily unavailable" for Solaris For Solaris 2.4, this s a kernel bug. Get the patch 101945-37 to fix it. Please note that at least one earlier version, 101945-36, seems to have reintroduced the bug. If you experience the same problem with Solaris 2.5.1, upgrade to ssh 1.2.14 or later, which should have solved the problem. 5.3. Sshd hangs under Solaris 2.5! This is a problem with the Solaris shared library code, which causes a hang with some name server functions. Get Patch 103187-02 (for x86, 103188-02) to fix this. This problem may or may not be fixed in Solaris 2.5.1. 5.4. X11 forwarding does not work for an SCO binary with the iBCS2 emulator under Linux. You need to set the hostname to the fully qualified domain name for this to work. Some Linux distributions set the hostname to the first part of the FQDN only. 5.5. Ssh is doing wrong things for multi-homed hosts! Check whether gethostbyname() really returns the complete lists of possible IP addresses (you might, for example, have your system configured to search /etc/hosts first, which might contain only one of the IP addresses). 5.6. Userid swapping is broken under AIX! This is a bug in AIX 3.2.5, reported as APAR IX38941, and fixed by patches U435001, U427862, U426915, and a few others. Contact your IBM representative for details. 5.7. ssh-keygen dumps core on Alpha OSF! For Alpha OSF/1 1.3.2, this is due to a bug in the vendor-supplied compiler with maximum optimization. Turn off all optimization for ssh-keygen, or use gcc. Gcc 2.7.2 is known to have problems on the Alpha, however. 5.8. ssh-keygen dumps core on Solaris or SunOS This is a bug in gcc 2.7.0, which causes it to generated incorrect code without optimization. Supply the "-O" or "-O -g" options to gcc when compiling. Alternatively, upgrade to gcc 2.7.2. 5.9. On Linux, compilation aborts with some error message about libc.so.4 This is an incorrectly configured Linux system; do a "cd /usr/lib; ln -s libc.sa libg.sa" as root to remedy this. 5.10. X authorization sometimes fails. This is believed to be a bug in HP-UX 9 xauth, SR 5003209619. Patch PHSS_5568 is believed to fix this problem. If this occurs for any other platform, please mail details to ssh-bugs@clinet.fi. 5.11. Ssh asks me for passwords despite .rhosts! There are several possibilities why this could be the case; common ones include o The client host key is not stored in the known_hosts file. Note that this has to be the canonical (usually, the fully qualified) domain name. o The client host does not have a reverse mapping in the name servers. Note that ssh requires that it has both a reverse mapping, and a forward mapping that contains the original IP address. o A multi-homed client or host does not have all of its IP addresses listed in the DNS entry. Note that versions prior to 1.2.12 have bugs in handling multi-homed hosts. o User's home directory or ~/.rhosts is world or group-writable (see StrictModes server configuration option). o On some machines, if the home directory is on an NFS volume, ~/.rhosts and your home directory may need to be world-readable. o The root account has to use ~/.rhosts or ~/.shosts; /etc/shosts.equiv and /etc/hosts.equiv are disregarded for root. o Confusion between RhostsRSAAuthentication and RSAAuthentication. RhostsRSAAuthentication is a functional replacement for the 'r' utilities; this requires the ssh program to be setuid root, a secret key in /etc/host_key file on the client, a corresponding public key entry in /etc/ssh_known_hosts, plus entries in ~/.[sr]hosts or /etc/[s]hosts.equiv. RSAAuthentication is done on a per-user basis and requires a ~/.ssh/identity file on the client side (to be generated with ssh- keygen), plus a matching ~/.ssh/authorized_keys on the server side. 5.12. Why does ssh loop with "Secure connection refused'? This is a configuration problem. Ssh attempts to fall back to the "r" commands when it cannot connect to an ssh daemon on the remote host. It does this by execing your old rsh to use the old protocol. There are two possibilities why this could be: o You probably have installed ssh as rsh, and forgotten to give the --with-rsh=PATH option to configure the second time. When ssh is looking for rsh, it keeps executing itself (or an older version of itself). To solve this, recompile ssh with the correct place for rsh. o You moved the old rsh and rlogin into a different directory and correctly are calling the old rsh. The old rsh has a hard-coded path to the old rlogin program, so you wind up execing the old rsh which in turn execs the new replacement (ssh)rlogin. In that case, you might want to move the old rsh and rlogin binaries into /usr/old, patch the old rsh binary by running the Perl script perl -pi.orig -e 's+/usr/(bin|ucb)/rlogin+/usr/old/rlogin+g ;' /usr/old/rsh which will generate a patched version of rsh and save the old one in /usr/old/rsh.orig. Reconfigure ssh with --with-rsh=/usr/old/rsh. 5.13. ssh-agent does not work with rxvt! rxvt closes all file descriptors when starting up, including the one used by ssh-agent. Use xterm, or look at the mailing list archives at http://www.cs.hut.fi/ssh/ssh-archive/ for Timo Rinne's rxvt patch. 5.14. X authorization always fails. This can happen if the xauth program was not found at configure time. Correct the path, reconfigure and recompile. 5.15. ssh hangs when forwarding multiple TCP connections. This is due to a known race condition in the ssh protocol before 1.2.13. Some changes have been made to the protocol in 1.2.14 to prevent this. Unfortunately, these changes may also cause hangs when using TCP forwarding between 1.2.14 and earlier versions. In these cases, upgrade to 1.2.14 or later at both ends is recommended. 5.16. What does Warning: remote host denied X11 forwarding mean? Either the remote end has disabled X11 forwarding (ForwardX11 No in the config file), or either the xauth command or the X11 libraries were not found when compiling the server. 5.17. I still see cleartext packages on the net when I run ssh! It is very likely that you are looking at a telnet, rlogin or X session to the machine that you run ssh on. Check that those packets really are ssh packets (for example by checking their port number; sshd listens on port 22). 5.18. I have problems with RSAREF, something to do with too many bits! This is a limitation in the RSAREF library. You should set a host key with at most 896 bits. 5.19. Compiling fails with some error messages from the assembler. For several operating systems there were bugs in the gmp assembler routines. Try make distclean configure --disable-asm to compile. 5.20. Compiling with Solaris 2.5 fails! Set the CPP environment variable to "cc -E -Xs" before running configure. 5.21. Ssh suddenly drops connections! This is a problem which has been reported by several people for SunOS 4, Solaris 2, Linux, and HP-UX 9 and 10, with 1.2.16 and 1.2.17. It happens with scp, when transferring large amounts of data via ssh's stdin, or when forwarding an X connection which receives a large amount of graphics data (such as a MPEG movie). Try to apply the following patch to 1.2.16 or 1.2.17 for a fix. This is in 1.2.18 or later. --- serverloop.c.orig Tue Jan 21 14:38:25 1997 +++ serverloop.c. Tue Jan 21 14:37:54 1997 @@ -405,7 +405,7 @@ buffer_len(&stdin_buffer)); if (len <= 0) { - if (errno != EWOULDBLOCK) + if ((errno != EWOULDBLOCK) && (errno != EAGAIN)) { if (fdin == fdout) shutdown(fdin, 1); /* We will no longer send. */ 5.22. Connections are forwarded as root by ssh! When a client connects, sshd forks a child that does the protocol handling, and this child forks a second child for the user shell or command. The problem is that the setuid() call to the correct user appears only in the second child, so the first child keeps running as root. Among other potential problems this means that connections redirected with -Lx:host:port will be made from the root uid to host:port, since the first child does them. This means that when the target host does an ident query, it gets back only "root" and no indication of the actual user. This has been reported as a bug; it is not known wether this will be fixed in a future release. 6. Miscellaneous 6.1. What known security bugs exist in which versions of ssh? All versions of ssh prior to 1.2.12.92 had a security flaw which allowed local users to get access to the secret host key. This is fixed in 1.2.13 and later. If you run ssh 1.2.13 on Alpha OSF 1.3 or SCO in C2 security mode, local users can gain root access. This is fixed by applying ftp://ftp.cs.hut.fi/pub/ssh/ssh-osf1-c2-setluid.patch or by upgrading to 1.2.14 or later. Versions of ssh prior to 1.2.17 had problems with authentication agent handling on some machines. There is a chance (a race condition) that a malicious user could steal another user's credentials. This should be fixed in 1.2.17. The arcfour cipher is used in a way which makes it susceptible in version 1 of the ssh protocol. Therefore, its use has been disabled in 1.2.18 and later. 6.2. How widespread is use of ssh? As with every piece of freely available software, this is difficult to find out. The best current estimates are that at least 1000 insitutions in 40 countries use it. This estimate is based on o The number of people on the ssh mailing list, around 600, from 40 different countries and several hundred domains o Each week, the ssh home pages are accessed from roughly 5000 different machines, many of them web caches; also, these machines often are different from week to week. 6.3. I don't like the commercial aspects of ssh. The protocols ssh uses are freely available. There are no restrictions if anybody wants to write a version that is available under different conditions and is interoperable with existing ssh installations. Ssh is also on the Internet Standards Track. This means that a second, independent implementation is required. You will have to be aware of patent (RSA, IDEA) and export control issues before writing a second implementation. 6.4. Credits Most of the credit, of course, goes to Tatu Yloenen for writing ssh and making it available to the public. I have also used parts of his text from the documentation accompanying the ssh source distribution. Thanks also for his corrections for this FAQ. Also of invaluable help were corrections and additions from members of the ssh mailing list and the Usenet newsgroups, by Mark Martinec, Pedro Melo, Michael Soukas, Adrian Colley, Kenneth J. Hendrickson, Adam Hammer, Olaf Titz, David Mazieres, Axel Boldt and Wayne Schroeder. -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBM5hHefBu+cbJcKCVAQHSYgQApNeQZNsnycO79/S6hTjzPEs69U2SglTZ jYMe57kh3sDamnXoMJEh/XpHFSRm1G3BXqcNkwsZhrOxExXKjMlxwRhPSNI5BZnn 4qMIYY7zHauhbMdvfIrj5nsfiLN1v1tQJc5txAo5//WNJ6Q5PMe+jAWzCuiwiIBb /jlkYJGJFr0= =VsnS -----END PGP SIGNATURE----- -- Thomas Koenig, Thomas.Koenig@ciw.uni-karlsruhe.de, ig25@dkauni2.bitnet. The joy of engineering is to find a straight line on a double logarithmic diagram.